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1. INTRODUCTION AND SUMMARY 


Study Z. 1, Operations Analysis, addressed two major 
subjects related to future STS operations concepts. The majority of 
effort was directed at assessing the benefits of automated space ser- 
vicing concepts as related to improvements in payload procurement and 
Shuttle utilization. The second subject was directed at understanding 
Shuttle upper stage software development and recurring costs relative 
to total program projections. 

1. 1 SPACE SERVICING CONCEPTS 

Space servicing of automated payloads has the potential 
to reduce future space program costs and provide a great deal of flexi- 
bility relative to conducting mission operations. The subject is 
addressed in this effort by examining the broad spectrum of payload 
applications with the belief that shared logistic operations will be a 
major contributor to reduction of future program costs. However, 
there are certain requirements for support of payload operations, 
such as availability of the payload, that may place demands upon the 
Shuttle fleet. Because future projections of the NASA Mission Model 
are only representative of the payload traffic, it is important to recog- 
nize that it is the general character of operations that is significant 
rather than service to any single payload program. 

Space servicing, as employed for this Study, implies 
an ability to extend the life of a given payload by replacing modular 
increments rather than a complete payload. In so doing, the total 
weight to orbit can be reduced; also, the feasibility of sharing flight 
operations moves closer to reality, both of which contribute to 
reduced operating costs. However, failure patterns over such a 
broad spectrum of payloads will inherently be random and this ran- 
dom nature may place demands for servicing at a time when the Shuttle 
is occupied with other commitments, such as sorties. So it is impor- 
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tant to see if savings can be realized without undue penalty to eithe; 
the payload community or the Shuttle community. 

To assess space servicing, it was necessary to develop 
an entirely new data base of payload definitions. Weight and relia- 
bility characteristics are the principal features required. In addition, 
it was necessary to develop a computer simulation program to repre- 
sent the various elements of each payload and simulate the random 
pattern of failure events. Although the total model is considered, 
emphasis has been placed on servicing payloads in geostationary orbit. 
The results indicate that a substantial cost benefit can be realized 
sufficient to compensate for DDT&E costs associated with the payload 
and service mechanism design efforts as well as the associated ser- 
vicing operation. 

1 . 2 PAYLOAD/TUG SOFTWARE COST ESTIMATES 

Software costs were addressed because very little firm 
data exist. Speculation of software costs for the upper stage, especially 
if servicing is employed, has provided a broad band of cost estimates. 
Consequently, the effort here was devoted to developing an understand- 
ing of the driving factors affecting software costs and then developing 
sufficient data to allow a valid estimate of upper stage or T- sts 
that may be incurred in the future. 

The results of this effort indicate that existing u.,jt Esti- 
mating Relationships (CERs) are insufficient in the present form but 
can provide a basis of understanding. Modifying factors were developed 
based upon such historical data as Apollo, Titan IIIC, and Centaur pro- 
grams and applied to airborne, ground support, and mission control 
center software costs. It is estimated that software development costs 
for the Shuttle upper stage including multiple rendezvous, docking, and 
servicing functions should not exceed an initial cost of $21 million, with 
a recurring cost of $2. 5 million annual’/. 
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2. SPACE SERVICING CONCEPTS 


<L 1 GENERAL 

Study 2. I, Operations Analysis, had as its principal 
objective the investigation of new operational concepts for the Shuttle 
era. Attention was directed primarily at space servicing of automated 
payload programs and the impact this could have on upper stage designs 
and overall resources utilization. Although this is not an economics 
study, cost benefits resulting from space servi< ing can be determined 
in a gross sense so that the concept can be pursued further within NASA, 
or included in detail design studies with other contractors. 

To perform this study it was necessary to develop an 
entirely new data base and analysis technique. C; ndidate payloads 
were selected from the October 1973 NASA Mission Model of Automated 
Payload Opportunities and reconfigured for space servicing. This design 
process resulted in a set of standard space replaceable units (SRUs) which 
serve as the builuing blocks of each serviceable payload. Mission equip- 
ment for each candidate payload was also reconfigured for space servicing. 

A complex computer simulation program was developed to 
support the analysis of space servicing. This statistical program employs 
Monte Carlo techniques to establish failure events which then require ser- 
vicing by the Space Shuttle with an upper stage to put the payloads back into 
an operating condition. Various upper stage configurations can be 
employed in the analysis. The computer program has been implemented 
for NASA use at the NASA Computation Facility, Slidell, Louisiana. 

Although space servicing of automated payloads appears to 
be attractive for individual programs, in the past it has not been shown 
ihat its application in a broad sense would be beneficial. Since servic- 
ing operations are random in nature, they may place severe demands on 
the logistic fleet which could otherwise be occupied by operations such 
as Sorties. Consequently, the total mission model must be considered 
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and the following questions assessed: 

1. Can the total number of flights be reduced by space 
servicing of payloads? 

2. Can the total payload procurement be reduced? 

3. Are the benefits sufficient to justify the DDT&E 
costs and the risk associated with developing a new 
concept ? 

2. 2 PAYLOAD RECONFIGURATION FOR SPACE SERVICING 

This portion of stuOy effort was divided into several sub- 
tasks, all associated with developing data and performing subsequent 
tradeoff analyses. The most important of these was the development 
of a space serviceable payload data base. Information from several 
detailed payload redesign efforts was employed together with the results 
of this study to provide a composite of subsystem and mission equipment 
weights, volumes, and reliabilities. This new data base has been issued 
as an Aerospace report (Ref. 1). A summary of the content is provided 
below. 

The subsystem requirements for 42 payload programs were 
evaluated to establish the range over which any set of standard equipment 
would have to perform. Four subsystem categories were selected: Atti- 

tude and Velocity Control, Guidance and Navigation, Tel-metry and Com- 
mand, and Electrical Power. Certain high reliability components were 
incorporated with the basic structure of each payload to form a non- 
replaceable unit (N'RU). This was the framework within which the space 
replaceable units (SRUs) could be inserted and removed as required for 
servicing. Mission equipments were also placed upon SRU baseplates 
to be replaced either because of failures or for equipment improvement. 

This information was then u«ed to reconfigure an example 
satellite for space servicing. The selected design was the NASA Earth 
Observatory Satellite (EOS). The baseline definition is shown along with 
its reconfigured version in Figure 1. The mission equipment modules are 
principally located around the periphery of the ring frame to allow for 
future growth of equipment. Subsystem modules, where the size can be 
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controlled, are loca ed inside the ng frame. This general configura- 
tion was then employed for the remaining space serviceable payload 
candidates. In all, Z 9 different designs were developed to satisfy the 
payload programs. Thirty-four different subsystem SRUr were 
required along with 104 mission equipment modules. In general, the 
weight growth for payloads over 1000 kg (current design) was 10 to 30 
percent. 

A sample of this technique is illustrated in Table 1. The 
telemetry tracking and command (TT&C) requirements for various 
sets of payloads under consideration were summarized as shown in 
this example. These requirements were then transferred into a set 
of subsystem block diagrams as shown in Figure Z, each diagram sat. 
isfying a specific set of the payload requirements. This then defines 
the design elements of one of the TTfrC space replaceable units (SRU). 

Each block diagram is further broken into specific com- 
ponents, necessary to meet specific payload requirements, such as 
transmitter frequency and power levels, type of receiver, etc. A 
typical component list for TT&C-4 is shown in Table Z, listing the 
number of components required and their associated failure rates. 

It is now possible to make use of the reliability block diagram shown 
in Figure 3 to develop the associated reliability characteristics. This 
diagram reflects both active and standby forms of redundancy for various 
components. Payload requirements dictate a mission life of no less than 
three years. The derived SRU would therefore have a reliability at that 
design life of 0.883. The associated Weibull parameters express the 
shape of the reliability curve and serve as input discriptors for the 
simulation program. This particular SRU (TT&C-4) was assigned to 
three different payloads. In all, 10 different SRUs were required with 
three variants (tape recorder options) to satisfy the complete spectrum 
of payloads considered. 

The remaining subsystems were treated in a similar manner 
resulting in 11 different attitude and velocity control subsystems (A. VCS), 
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1’able 2. SRU Component Characteristics (TTC-4) 
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and 2 guidance and navigation subsystems (GfcN), and 7 Electric , i Power 
Subsystem modules which could be replaced on orbit. Base plates and 
power supplies were added to each SRU design and weight and reliability 
estimates were developed as described above. Mission equipment module 
were developed in essentially the s:-.me manner to arrive at a total inven- 
tory of SRUs and NRUs to be used to compose each space serviceable payl 

An example of this process is shown in figure 4. This 
shows the reliability block diagram of the payload and specifies its per- 
tinent characteristics. This process was performed for each of the 29 
different payload designs to be used <n subsequent tradeoffs. 

It is important to note tl e various levels of redundancy 
assumed because the simulation process must reflect this in respond- 
failure conditions. If for example two of four AVCS-7 SRUs 
, reaction control units) are required to maintain stabilization of the 
payload, it would not be necessary to demand an immediate servicing 
operation if one SRU failed. If a second unit failed, however, a servic- 
ing flight would be required because any subsequent failure would be 
interpreted as loss of the payload. These are arbitrary ground rules 
but are easily changed in the simulation process. The significant point 
is, however, that each payload has unique characteristics which create 
different requirements for servicing, even though standard modules are 
employed. This approach should be representative of the operational 
process which would exist if space servicing is incorporated on a broad 
applications basis. 

2. 3 SPACE SERVICING TRADEOFFS 

The fundamental tradeoff addressed the relative cost 
of space servicing of automated payloads versus expendable pay- 
load design concepts. In addition, various upper stages were con- 
sidered to determine the sensitivity of space servicing benef ts to 
the selection of an upper stage. Upper stage candidates employed in 
this study were the modified Titan 1 110 Transtage, the Transtage with a 
kick motor, a 28-foot large-tank Centaur, the full capability Tug, and a 


EO-7 Synchronous Meteorological Satellite 



* 


Figure 4. Space Serviceable Payload Definition 
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Centaur/SEPS (Solar Electric Propulsion Stage) combination. 

The results presented here have been limited to geosta- 
tionary orbit payloads. Further effort is required to place the remain- 
ing orbits of interest in proper perspective. There are 16 different 
payload programs scheduled for geostationary orbit in the time period 
of 1980 through 1990 (11 years). Approximately 60 percent are COMSAT- 
type programs, 30 percent are earth observations, and 10 percent are 
Explorer-type programs. The total number of operational payloads in 
geostationary orbit at any given time ranges between 30 and 40. 

The servicing process consists of recording when a fail- 
ure event occurs in each payload deployed to geostationary orbit. The 
replacement SRU is then placed in a loading queue to await delivery to 
the payload of interest. As other failures occur, the process of load- 
ing is continued. When a full load, compatible with the Shuttle and the 
upper stage under investigation is achieved, the combined load is deliv- 
ered to orbit. The payloads are then placed in an operational state to 
await the next failure event. This procedure is repeated through a 
Monte Carlo process to arrive at a statistical distribution of SRU 
replacements and logistic vehicle operations. Cost estimates can then 
be implied by equivalent payload procurement and vehicle launch costs. 

The results of this simulation effort are shown in Figure 5 
indicating the degree to which each payload is serviced over the time 
period of interest (1980 - 1990). This curve shows that each space 
serviceable payload required at least a 6 percent replacement of equip- 
ment, and that 20 percent of the payloads required, on the average, a 
replacement of approximately 40 percent of their equipment. The 
results are related to the NAS>\ full capability Tug but only slight changes 
occur when other upper stages are employed. The average payload avail- 
bility shown indicates that, in general, a value above 95 percent is readily 
achievable without the use of orbital spares or dedicated logistic opera- 
tions. An i.i-depth analysis is required if availabilities above 99 percent 
are desired, as is ' e case with commefcial communication satellites. 
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Table 3. Simulation Results 
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During this time period, 32 space serviceable payloads 
were deployed to establish operational systems in geostationary orbit. 
Nine of these payloads had failures of non- replaceable units, thereby 
forcing a total payload replacement to maintain continuity of the program 
In addition, on the average, over 145 space replaceable units (SKUs) wer 
replaced, representing an equivalent payload procurement of 10 addition.* 
payloads. The total procurement of space serviceable payloads for geo- 
stationary orbit is therefore estimated to be approximately 51 payloads. 

In addition, during this same time period, approximately 13 expendable 
payloads (not suitable for space servicing) were deployed, providing a 
total payload procurement of 64 payloads to fulfill the geostationary oper- 
ational objectives of the October 1973 Mission Model. If space servicing 
were not employed, a total procurement of 96 expendable payloads (with 
equivalent reliabilities) would be required to provide the same level of 
support to operational programs. This represents, conservatively, a 
30% improvement in payload procurement costs. 

These results are summarized in Table 3* for various 
upper stage configurations. The baseline case is taken as the Transtage/ 
kick motor operation which recovers the Transtage, but employs expend- 
able payload designs. The required number of flights is reduced as the 
performance capability of the selected upper stage is increased. In per- 
forming the analysis, a reduction of one Shuttle flight was assumed to 
provide a savings in cost of operations of $10 million. However, in cer- 
tain cases, it was necessary to expend the upper stage, resulting in addi- 
tional procurement costs. For example, if the Transtage were expended 
to deploy payloads, the total number of flights would be reduced from 83 
to 54 (35%), saving approximately $290 million in flight operations' costs 


*Theae results have been extended to additional modes of space servicing 
with improved loading criteria, as documented in an Aerospace report 
(Ref. 2). 
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but forcing the purchase of an extra 35 upper stages at approximately 
$b million each. As a result, the overall return after 11 years of opera- 
tion still favors expending the Transtage over the baseline mode by as 
much as $93 million. This reflects the fact that even though the baseline 
mode of operations normally recovers the Transtage, on the average it 
was necessary to expend 19 stages, in addition to the kick motors, 
because payload weights were sufficiently high that stage recovery could 
not be achieved. 

Again, for expendable payload operations, a large tank, 

28-ft long Centaur has sufficient performance to deploy all the pay loads 
in the mission model without the need to expend any of the Centaurs. A 
further, although small, reduction in the number of Shuttle flights results 
from the use of the full capability Tug, again wi.hout expending any pro- 
pulsive stages. The return on investment over the 11 -year period is 
essentially the same for both vehicles, although the DDT&E is consider- 
ably greater for the Tug. It is possible that other high energy missions, 
such as planetary, may require the higher performance of the full capa- 
bility Tug. However, for expendable payload operations in synchronous 
equitorial orbit, based on the reference mission model, it would appear 
that a large-tank Centaur is adequate. 

Continuing with the results presented in Table 3, it can be 
seen that space servicing offers significant cost benefits over expendable 
payload operations. 

The Centaur stage used in this space servicing analysis is 
based on the current design and incurs a loss of 1454 kg (3200 lb) when 
used in a seven-day mission. This penalty is very severe and results in 
a high flight rate even though the number of procured payloads is reduced. 

It also requires the expenditure of a significant number of stages to accom- 
modate the increased payload weights associated with space servicing. 
However, the boiloff rate and other losses of the Centaur must be reduced 
before its orbital performance could be sufficiently improved to make it a 
viable candidate for space servicing. A reduction of 454 kg in the boiloff 
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would reduce the Shuttle flight rate as shown in Figure 6. Although 
this boiloff rate is still considerably higher than for the Tug, it would 
result in a cost saving of approximately $150 million due to the reduc- 
tion in Shuttle flights. Since the estimated DDT&E cost to achieve this 
level of boiloff is less than $10 million, it appears to be a worthwhile 
investment. 
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Impact of Boiloff on Centaur Capability 



It is recommended that a thorough review of the Centaur 
design be performed, preferably by the manufacturer, to assess its poten- 
tial capability (and associated costs) for space servicing, since the Centaur 
results are very sensitive to inert weight and orbital life. 

It can also be seen from Table 3 that the full capability Tug, 
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which is being designed to perform a seven-day orbital mission, can 
substantially reduce the Shuttle flight rate, leading to a return on invest- 
ment of approximately $700 million over the baseline case for the 11- 
year period. 

This significant cost saving is considered to be conservative 
for several reasons. First, flight costs will probably be closer to $12 
million per flight because of the additional upper stage functions. Second, 
an average payload will probably cost more than $10 million. While com- 
munication satellites currently cost approximately $7 million, other opera- 
tional and scientific payloads, which are highly complex, are expected to 
cost over $40 million each. Finally, no effort was made to optimize the 
flight operations; as a result, payloads were serviced as failures occurred 
without exercising priorities, leading to relatively poor upper stage load 
factors of only 65 percent. 

Although further improvement could be achieved by additional 
analysis, it is obvious that space servicing can offer a substantial payoff 
in a relatively short period of time. An initial DDTbE investment of 
over $100 million to achieve space serviceable payload configurations 
would be returned in five to six years. Since a return on investments 
of this magnitude generally requires 10 to 20 years, the cost benefits 
cannot be ignored. Moreover, the average time for advancing technologies 
to create a new generation of payload configurations has been found to te 
approximately six years; thus, a given payload program can upgrade its 
payload configuration and realize a return from space iiervicing within the 
first generation of the program plan. 

A further poin'. ot importance i» the 1 .a.iibiilty of design and 
operation that space servicing offers. Improvement in mission equip- 
ment can be incorporated as they become available, rather than requir- 
ing a new payload design. If a given program drops behind schedule or 
cost overruns are imminent because of a single equipment item, the 
requirements can be relaxed to meet the initial deployment schedule 
knowing that an improved version of the equipment can be installed on- 
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orbit at a later date. Since the subsequent equipment replacement would 
only bear a fraction of the flight cost, as compared to a total payload 
replacement, it may be possible to reduce the total runout costs while 
at the same time meeting the initial flight schedule. 

An alternative to increased orbital lifetime for the Centaur 
is to couple its operation with that of a space-based Solar Electric Pro- 
pulsion Stage (SEPS). Although a complete analysis could not be performed, 
it is possible to extrapolate previous manual calculations to this mission 
model. In this mode the Centaur performs two functions: direct payload 

deployment of all payloads (including SRUs) not requiring a SEPS, and sup- 
ply of payloads to the SEPS when the Centaur performance will not allow 
geostationary operations. In this way, payloads requiring immediate ser- 
vicing could be accommodated by the Centaur, whereas heavy payloads 
exceeding the Centaur capability would employ a SEPS, making it unneces- 
sary to expend any Centaurs. The SEPS, after receiving payloads and 
SRUs from a single Centaur flight, then will transfer from position to 
position to service numerous payloads in orbit. Initial deployment and 
retrieval of the SEPS is performed by the Centaur. 

The reference SEPS is a 25 kW configuration with approxi - 
mately 1360 kg (3000 lb) of mercury propellant, achieving a specific 
impulse of 3000 seconds. Although deployment and retrieval oper i ons 
may require 20 to 30 days, the servicing time in geostationary orbit 
quite competitive with the full capability Tug, in the order or two to 
three days. As shown in Table 3, the cost benefits exceed $800 million 
over the baseline reference case. In this case, the Centaur is quite 
competitive with the full capability Tug because orbital lifetime is not 
a problem. The additional $100 million to $150 million savings should 
be sufficient to cover adaptation of the SEPS to space servicing, assum- 
ing that the SEPS is developed for planetary operations. In fact, the 
benefits are such that it may be possible to compensate for the total 
SEPS development cost, although further optimization would be required 
to obtain definitive results. 
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2. A CONCLUSIONS 

Although a great deal of analysis is still needed, it is 
apparent from the results developed in this study that space servicing 
should be pursued, especially for geostationary orbits. The potential 
benefits in terms of costs, flexibility for equipment changes, and 
increased reliability of operations more than compensate for the pay- 
load weight increase and the associated investment required to develop 
this operational concept. However, it may be difficult to convince the 
payload users to take this step due to a concern over the risk of devel- 
oping the concept. Therefore, the following recommendations are 
submitted. 

2. 5 RECOMMENDATIONS 

One alternative is to initiate a pilot program prior to 
Shuttle IOC to demonstrate the operational technique. It may be possi- 
ble, using the USAF Space Technology Program (STP), to develop a 
simple payload experiment program that can be deployed with a replace- 
ment SRU after sufficient information is accumulated from the initial 
experiment. The service unit could be derived from several options, 
using existing equipments or prototype development items to maintain 
a low cost operation. Experience with the servicing unit should be 
beneficial also because it will aid in developing requirements and com- 
ponents for future upper stage operations, especially for rendezvous 
and docking operations. 

The advantage of this pilot program lies in focusing atten- 
tion on a new concept which must involve the payload user from the 
start. This involvement should enhance standardization of subsystems 
by emphasizing interface relationships and design guidelines. 

While a pilot program will not completely overcome the 
payload developer's reluctance to take the first step toward space ser- 
vicing because of uncertainty in the development risk, it should move 
the process much closer to reality. 
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3. PA Y LOAD/ TUG SOFTWARE COST ESTIMATES 


3. 1 SOFTWARE REQUIREMENTS 

In addition to the space servicing efforts discussed in 
Section 2, a functional analysis of upper stag*> operations was performed 
to establish the overall software requirements. For the purpose of this 
effort, the MSFC full capability cryogenic Tug was assumed to be the 
upper stage; however, the results are not particularly sensitive to the 
vehicle itself. Tug operations include the space flight and servicing 
functions as well as ground checkout and mission control center support. 
The functional analysis was based upon Titan IIIC experience for deploy- 
ment of expendable payloads. 

In parallel with the software requirements development, a 
survey of software costs was performed. This involved contacting several 
software and computer development firms to determine their procedures 
for estimating software costs. This also served to point out the major 
factors influencing software costs over and above the basic programming 
effort. The results of this effort are dc "umented in an Aerospace Techni- 
cal Report (Ref 3). A summary is provided below. 

From the functional analysis it wat determined that the space- 
bc rne software would require approximately 30,000 words of instructions 
to perform space servicing. An additional 2,000 words would be required 
for the service unit sequencer. These functions include orbital transfer, 
navigation updates, rendezvous and docking, and other support functions. 

Ground checkout software functions were estimated to require 
over 1 million words of instructions for Tug preparations. The service 
unit would require an additional 100,000 words. This estimate assumes 
that the overall ground support operations are managed by a large compu- 
ter complex similar to the Launch Processing System currently envi- 
sioned for the Kennedy Space Center. As such, many peripheral functions 
would be required in support of the Shuttle and could be shared by the upper 
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stage with no impact. 

A similar approach was assumed for the Mission Control 
Center (MCC) functions. The MCC is required to support Shuttle opera- 
tions, including all telemetry conditioning, tracking and navigation 
updates, display formatting, and command uplink capability. As such 
the additional support required for the upper stage and servicing func- 
tions is estimated to have a minimal impact on the flight support func- 
tions. For this reason, it was estimated that approximately 30,000 words 
of instruction would be required plus an ?»iitionql 5,000 words to support 
the service unit. 

In developing these estimates, serious consideration was 
given to two other points which bear on the software requirements. One 
is that all payload checkout operations are performed by the payload user, 
not by the Tug or service unit. The service unit exchanges space replace- 
able units (SRUs) and verifies proper insertion, but that is the extent of 
the service operation. This is particularly significant when considering 
the wide variety of payloads to be serviced. To expect one universal 
checkout system to exist on the service unit is unrealistic. The second 
point concerns Tug/service unit and payload responses to contingencies and 
the possible need for manned interactive support. A brief contingency 
analysis was performed (Ref 4), which indicates that a visual check of the 
payload configuration prior to docking is necessary to assure a clear path 
of approach. Consequently, the above software estimates are based upon 
automated servicing operations with a command override capability from 
MCC to support a stand-off and inspection maneuver before and after ser- 
vicing. 

The impact of the above software requirements cannot be 
assessed without some basis for estimating future software costs. Soft- 
ware costing has always been elusive and difficult to predict for several 
reasons. In surveying various contractor efforts, the one point that con- 
tinually arose was the lack of firm software requirements. This tends to 
negate any software cost estimating relationships (CERs). Although 
actual software costs may exist, it is difficult to relate these costs to 


- 20 - 


an original set of requirements. The approach taken, therefore, was to 
establish a basic cost estimate related to the words of instruction and then 
use modifiers to adjust this cost based upon empitical judgment factors. 

The results of the survey are shown in Figure 7. Various 
programs are shown relative to the number of words in machine language 
versus the man months of effort to develop, code, and check out the pro- 
gram. It should be recognized that in several cases the points shown do 
not represent total program efforts, but only a portion for which data 
could be found. This is sufficient for developing the relationship shown. 

It should also be noted that a band for the updated Titan IIIC airborne com- 
puter is provided. This band reflects the fact that although a fixed word 
count exists there are several contractors involved and therefore the actual 
cost, including integration, may be double that derived from the curve. 

This point is discussed next. 

Five factors were considered as modifiers of the basic rela- 
tionship shown in Figure 7. They are computer capacity, program com- 
plexity, prior experience, coding language, and level of integration effort 
required. When taken together, these factors, based upon a manpower 
cost of $4000 per man month, increase the basic spaceborne software 
cost from $3. 93 million to $9. 91 million, a lactor of approximately 250 
percent. 

Similar approaches were taken for ground checkout and 
flight support hardware. Basic cost ratios range from $200 per word for 
spaceborne systems to $7 per word for ground and flight support. Adjust- 
ing these values for the five factors mentioned above provides the overall 
results shown in Table 4. The total developmental cost for a Shuttle 
upper stage is estimated to be approximately $21 million. Of this, less 
than 10% would result from s e additional functions related to space ser- 
vicing. In addition, it is es...nated, based upon Titan IIIC, Agena, and 
Centaur experience, that yearly recurring costs would be approximately 
$2. 5 million per year. 
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Table 4 Software Cost Summary 


TYPE 

DDT&E $M 


TUG 

SERV 

TUG 

St . 

SPACEBORNE 

8. 98 

| | 


0. 10 

GROUND SUPPORT 




0. 10 

FLIGHT SUPPORT 


in 


0. 05* 

TOTAL 

19. 28 

1.98 

■a 



$21. 26 

$2. 35/ YR 


‘ESTIMATED FROM T-lll AND SCF EXPERIENCE 
ESTIMATED THRESHOLD VALUES 



Figure 7. Software Cost Estimating Relationship 


- 22 - 














4 


I 


I 


l 


3. 2 


a. 


b. 


c. 


d. 


e. 


f. 


SUMMARY AND CONCLUSIONS 

In summary, the following conclusions are drawn: 

Manned interactive support is required for stand-off and 
inspection operations prior to and after space servicing. 

The majority of upper stage and service unit functions can 
be readily automated without a serious impact on the soft- 
ware costs. 

Total software costs for the upper stage program should 
not exceed approximately $21 million, of which less than 
10 percent would be due to servicing operations. This 
total represents only 5 percent or less of the overall upper 
stage development costs, which is considered to be very 
realistic. 

Recurring software costs, including program improvements, 
generation of new coefficients and preflight verifications 
efforts should not exceed $2. 5 million per year based upon 
an estimated flight rate of 10 flights per year. 

The lack of a firm software specification and the overall 
integration of the ooftware effort will probably be the major 
factors involved in software costs and should be tightly con- 
trolled from the outset of program initiation. 

New techniques need to be developed to reduce future soft- 
ware costs, such as structured programming or standardiza- 
tion of software modules. NASA GSFC has been investigat- 
ing these techniques in an effort to keep spiraling costs in 
check. This type of work should be encouraged. 
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4. STUDY CONCLUSIONS 


The principal conclusion to be drawn from this Study effort 
is that space servicing, especially in geostationary orbit, is substan- 
tially more attractive as an operational concept than continued use of 
expendable payload designs. The potential savings in payload procure- 
ment and logistics cost over an 11 -year period should be more than suf- 
ficient to compensate for associated DDT&E costs. In addition, the capa- 
bility to modify the mission equipment as new designs evolve offers unpar- 
alleled flexibility for performing scientific programs at substantial savings. 

This effort has been restricted in depth but the general char- 
acter of future operations can be assessed. For example, the random 
demands for servicing do not appear to place any severe demands on 
fleet size. The overall flight rate is in fact reduced substantially, while 
still maintaining a relatively high payload availability. The average down 
time, when a critical failure occurs, should not exceed 60 days on the 
average. Also, it can be expected that, on the average, 25 percent of 
the modules within a given satellite will require replacement to satisfy 
the requirements of the reference NASA Mission Model. 

The results further indicate that study activities should be 
directed toward space ba '*ed servicing operations in geostationary orbit. 
Consequently, although further analysis is needed, it is very apparent 
thai this concept should not be precluded when considering development 
of a servicing capability. 

Finally, a recommendation is made to initiate a low cost 
pilot flight test program to demonstrate automated space servicing to the 
payload community. The objectives of such a test are to develop confi- 
dence in the concept, demonstrate that the associated technical risk is 
minimal, and to show that operational procedures are adequate to sup- 
port this concept. Further work is planned on this subject in the next 
Study effort to be initiated in September 1974. 
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It has also been shown that software costs associated 
with the upper stage for rendezvous, docking, servicing, or retriev; 
operations do not impose a substantial cost burden on the Tug develop- 
ment. The costs are not expected to exceed $21 million for develop- 
ment with a recurring annual cost not to exceed $2. 5 million. The 
impact of servicing is predicted to be relatively minor, less than 10 
percent of the total software costs. Consequently, there is no reason 
to suspect that software development represents a severe risk to the 
Tug development or to space servicing operations. 


REFERENCES 


1. M. G. Wolfe, OPERATIONS ANALYSIS (STUDY 2 'Payload 

Designs for Space Servicing (with Addendum ], Aliv- 74(7 34 3, 

The Aerospace Corporation, El Segundo, Calif. (30 June 1974). 

2. Space Servicing Pilot Program Study, ATR-75(736 1 )- 1, The 
Aerospace Corporation, E 1 Segundo, Calif. (30 January 1975). 

3. OPERATIONS ANALYSIS (STUDY 2. 1) Shuttle Upper Stage 
Software Requirements, A > TR-74(7 341)-4, The Aerospace 
Corporation, El Segundo, Calif. (15 July 1974). 

4. OPERATIONS ANALYSIS (STUDY 2. 1) Contingency Analysis, 
ATR-74(7341)-5, The Aerospace Corporation, El Segundo, 
Calif. (15 July 1974). 


- 26 - 



